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ABSTRACT: 

Methods and computer systems for providing access to a protected resource are described. In 
an enterprise computer system (300), an authentication server (302) provides a client (306) 
requesting access to the protected resource a credential (318). In order to access the protected 
resource, the requesting client (306) presents a protected resource access request in 
combination with the credential (318) to a server (304) coupled to the protected resource. The 
server (304), in turn, requests the authentication server (302) to validate the credential (318). 
After the authentication server (302) has validated the credential (318), the server (304) grants 
the requesting client (306) access to the protected resource. 
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(54) Distributed authentication mechanisms for handling diverse authentication systems in an 
enterprise computer system 



(57) Methods and computer systems for providing 
access to a protected resource are described. In an 
enterprise computer system (300), an authentication 
server (302) provides a ciient (306) requesting access 
to the protected resource a credential (318). In order to 
access the protected resource, the requesting client 
(306) presents a protected resource access request in 
combination with the credential (318) to a server (304) 



coupled to the protected resource. The server (304), in 
turn, requests the authentication server (302) to validate 
the credential (318). After the authentication server 
(302) has validated the credential (318), the server 
(304) grants the requesting client (306) access to the 
protected resource. 
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Description 

BACKGROUND OF THE INVENTION 

1. Field of Invention 

[0001] The invention relates generally to computer 
systems. More particularly, methods and apparatus for 
providing distributed authentication in an enterprise 
computer system. 

2. Description of Relevant Art 

[0002] In modern enterprise computing environ- 
ments, a number of personal computers, workstations, 
mainframes, and the like along with other devices such 
as large mass storage subsystems, network interfaces, 
as well as interfaces to the public telephony systems are 
interconnected providing an integrated environment in 
which information may be shared among the various 
users. Typically, users may be performing a variety of 
operations, including order receipt, manufacturing, ship- 
ping, billing, inventory control, and other operations in 
which sharing of data on a real time basis provides a 
significant advantage over, for example, maintaining 
separate records and attempting to reconcile them later. 
[0003] One problem that arises in an enterprise 
computing environment is that often the various users 
are using programs which have been developed based 
on a data or programming model that assumes that the 
data they receive, process, and store will be unique to 
that particular program. One solution to this problem is 
to force all types of programs to be constrained to the 
same type data or programming model. However, there 
are several problems with this strategy, one of which is 
for example that while constraining the enterprise com- 
puter system to a single platform may be efficient for 
some types of programs it can be very inefficient for 
other types of programs. 

[0004] Another strategy used to overcome the prob- 
lem of cross platform communication is to provide an 
information exchange engine that can translate data 
between platforms. While this will allow each program to 
have its own data or programming model, it requires 
acquiring and maintaining exchange engines for a 
number of programs and a user to select an appropriate 
exchange engine when importing or exporting informa- 
tion form another program. In addition, as the number of 
users and/or exchange engines increases in order to 
meet the needs of an expanding system, the intercon- 
nections between each of the components becomes 
prohibitively complex forming a 'spaghetti like mass". 
This increase in complexity effectively limits the scala- 
bility of an integrated set of computer resources since 
any additional computer resources require reconfigur- 
ing the entire system. 

[0005] As an example, Figure 1 is an illustration of a 
conventional enterprise computing system 100. The 



enterprise computing system 100 includes exchange 
engines 102-110 capable of accessing and cross con- 
nection of any number and type of information sources 
112 and 114. Such sources include various database 
5 management systems, applications programs, large 
mass storage subsystems, network interfaces, as well 
as interfaces to the public telephony systems such as to 
the internet. The database management applications 
generally include computer programs that are executed 
10 in conventional manner by digital computer systems 
over any number of computing platforms. Typically, the 
exchange engines include computer programs exe- 
cuted by digital computer systems (which may be the 
same digital computer systems on which their respec- 
ts tive applications programs are executed). The 
exchange engines and the application programs are 
processed and maintained on a number of digital com- 
puter systems interconnected by, for example, a net- 
work 116 which transfers data access requests, 
20 translated data access requests and responses 
between the computer systems on which the exchange 
engines and application programs are processed. As 
can be seen, as the enterprise computer system 
expands, the number of application programs and asso- 
25 dated digital computer systems increase to meet the 
needs of the expanded enterprise computer system. 
The scalability of this type enterprise computer system 
is poor since any substantial increase in the number of 
digital computers greatly increases the complexity of 
30 the network 116 which in turn greatly increases the 
resources required to maintain and upgrade the system 
100. 

[0006] One approach to solving the problems of 
cross platform communication and scalability is to use 

35 component based, multi-tier applications based on, for 
example, Enterprise JavaBeans (EJB) technology from 
Sun Microsystems Inc. of Mountain View, CA. Enter- 
prise JavaBeans technology, in the form of an EJB 
server, represents a multi-tier design that simplifies 

40 developing, deploying, and maintaining enterprise 
applications. It enables developers to focus on the spe- 
cifics of programming their business logic, relying on the 
EJB server to provide system services, and client-side 
applications (both stand alone and within web brows- 

45 ers) to provide the user interaction. Once developed, 
business logic can be deployed on servers appropriate 
to existing needs of an organization. 
[0007] Although EJB server technology substan- 
tially improves scalability and many of the problems 

so related to cross platform performance, there still 
remains the need to provide some form of cross plat- 
form security since a number of the computer systems 
within the enterprise computer system have their own 
authentication protocols and methods. 

55 [0008] Therefore, in view of the foregoing, it would 
be advantageous and therefore desirable to have a 
scalable, cross platform enterprise computer system 
having the capability of providing transparent multi-plat- 
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form security. 

SUMMARY OF THE INVENTION 

[0009] The invention can be implemented in numer- s 
ous ways, including as a method, an apparatus, and a 
computer system Several embodiments of the invention 
are discussed below. 

[0010] In one embodiment of the invention, a dis- 
tributed object computing system having an authentica- w 
tion server is described. The authentication server 
provides a credential that grants a credential owner per- 
mission to access a protected resource in the comput- 
ing system. The protected resource is identified in 
authentication data included in an associated credential is 
request that is provided by a requesting client. The 
authentication server includes a credential request veri- 
fier that determines if additional authentication data is 
required by the authentication server in order to grant 
the credential to the requesting client. A realm authenti- 20 
cator coupled to the credential request verifier that 
authenticates the requesting client in a requested realm 
when it is determined that the requesting client is 
allowed to access the requested realm. A credential 
translator coupled to the realm authenticator that grants 25 
a requested privilege in the authenticated realm to the 
requesting client when it is determined that the request- 
ing client is allowed the requested privilege in the 
authenticated realm. A credential generator coupled to 
the credential translator arranged to provide the creden- 30 
tial to the requesting client. 

[0011] In another embodiment of the invention, a 
method for accessing a protected resource coupled to a 
server in an enterprise computer system is described. A 
requesting client provides a protected resource access 35 
request to an authentication server. The authentication 
server uses authentication data provided in the authen- 
tication request to provide the requesting client a refer- 
ence to a credential. The requesting client, in turn, 
provides the reference to the credential in conjunction 40 
with a protected resource access request to the server 
coupled to the protected resource. The server requests 
that the authentication server validates by credential 
after which the server grants the requesting client 
access to the protected resource. 45 
[0012] In a preferred embodiment, the server is an 
Enterprise Java Bean (EJB) server. 
[0013] These and other advantages of the present 
invention will become apparent upon reading the follow- 
ing detailed descriptions and studying the various fig- so 
uresofthe drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] The invention, together with further advan- 55 
tages thereof, may best be understood by reference to 
the following description taken in conjunction with the 
accompanying drawings in which: 



Fig. 1 shows a conventional enterprise computer 
system; 

Rg. 2 shows an Enterprise Java Bean (EJB) server 
in accordance with an embodiment of the invention; 
Rg. 3 illustrates art exemplary multi-platform enter- 
prise computer system in accordance with an 
embodiment of the invention; 
Rg. 4 is a flowchart detailing a process for a client 
for obtaining a credential in order to access an 
object in accordance with an embodiment of the 
invention. 

Rg. 5A is a flowchart detailing the process for a cli- 
ent requesting a credential from an authentication 
server shown in Rg. 4 as operation 404; 
Rg. 5B is a transaction diagram detailing the 
request/response between the requesting client 
and the authentication server in accordance with an 
embodiment of the invention; 
Rg. 6 is a flowchart detailing a process for an 
authentication server authenticating a client in 
appropriate realms shown in Rg. 4 as operation 
406; 

Rg. 7 is a flowchart detailing a process 700 for 
translating the credential by the authentication 
server as shown in Rg. 4 as operation 408; 
Rg. 8 is a flowchart detailing a process for access- 
ing an object or other protected resource as shown 
in Rg. 4 as operation 412; and 
Rg. 9 illustrates a computer system that can be 
employed to implement the present invention. 

DETAILED DESCRIPTION OF THE EMBODIMENTS 

[0015] In the following description, frameworks and 
methods of providing for secure transactions in a multi- 
platform enterprise computer as described. Although, 
the invention will initially be described in terms of an 
authentication server residing in an Enterprise Java 
Bean (EJB) based enterprise computer system, the 
present invention can be used in any networked compu- 
ter system including those that include multi-threaded 
object oriented computer systems. 
[0016] In general, in an EJB based enterprise com- 
puter system having a number of interconnected EJB 
servers, when a requesting client application, such as, 
for example, an applet in a browser, desires to access a 
secure, or protected, data base or other resource, the 
requesting client application first locates an authentica- 
tion server. In one embodiment, the requesting client 
locates an authentication server by first accessing a 
name server that in response to a client request pro- 
vides an address for the authentication server. The 
requesting client then requests a credential from the 
authentication server. In one implementation, the cre- 
dential provides the requesting client with the ability to 
access a protected resource, such as an external data- 
base. In order to obtain the credential, however, the 
requesting client must first provide the authentication 
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server with information that includes which realm, or 
realms, the client desires to be authenticated. By 
realms, it is meant the user/name/auth date database 
contained on platforms, such as UNIX, Windows NT, 
etc. on which the object that the client desires to access 5 
executes. By way of example, if the client wishes to 
access a secure data base running in a UNIX platform, 
it must first request that the authentication server 
authenticate the requesting client in the UNIX platform 
on behalf of the requesting client w 
[001 7] Once the authentication server has authenti- 
cated the client in the appropriate realm (s), the authen- 
tication server then translates the privileges granted by 
the realm into the credential and returns a remote refer- 
ence to the credential to the client Tne client can then is 
use the remote reference to the credential for subse- 
quent access requests, such as for objects or protected 
resources such as data bases. By providing a remote 
reference to the credential, therefore, the invention is 
suitably disposed to run in any number and type of 20 
multi-threaded computer systems. 
[0018] One of the basic building blocks of an EJB 
based enterprise computer system is what is referred to 
as an Enterprise Java Bean (EJB) server. Fig. 2 illus- 
trates the architecture of an EJB server 200 in accord- 25 
ance with an embodiment of the invention. Since the 
EJB specification does not mandate any remote object 
"wire" protocol, the EJB server 200 can support multiple 
protocols like RMI, HOP (CORBA), and DCOM indicat- 
ing that a client to the EJB server 200 does not have to 30 
be written in the Java language. In the described 
embodiment, the EJB server 200 is a collection of serv- 
ices for supporting an EJB installation. These services 
include management of distributed transactions, man- 
agement of distributed objects and distributed invoca- 35 
tions on these objects, and low-level system services. In 
short, the EJB server 200 manages the resources 
needed to support an EJB component (or Bean) 202 
that is included in an EJB container 204. In the 
described embodiment, the EJB container 204 is a 40 
home for EJB components such as EJB component 202 
providing a scalable, secure, transactional environment 
in which EJB components can operate. The EJB con- 
tainer 204 handles the object life cycle, including creat- 
ing and destroying an object as well as handling the 45 
state management of EJB components. 
[0019] Since the EJB container 204 is transparent 
to a client 206, there is no client API to it When an EJB 
component is installed in the EJB container 204, the 
EJB container 204 provides two implementations: an so 
implementation of the EJB components EJB Home 
interface 208, discussed below, and the EJB compo- 
nent's remote interface. 

[0020] When a Bean is installed on the EJB server 
200, a remote interface referred to as an EJB Object 55 
210 is automatically generated. The EJB Object 210 is 
an object that exposes only the remote interface speci- 
fied by the programmer. In this way, the EJB Object 21 0 



acts like a proxy, intercepting any remote object invoca- 
tions and calling the appropriate methods on the enter- 
prise Bean instance. The EJB container 204 
Implements the EJB Home interface 208 of each Bean 
202 installed in the container. It allows for the creation of 
a Bean, deletion of a Bean and querying information or 
"metadata" about a Bean. 

[0021] Rg.3 illustrates an exemplary EJB based 
enterprise computer system 300 in accordance with an 
embodiment of the invention. The enterprise computer 
system 300 includes an authentication server 302 
securely coupled to a WEB server 304. In the described 
embodiment, the WEB server 304 is a Java based WEB 
server used for this example only and should not be 
construed as limiting the scope of the invention. The 
WEB server 304 is, in turn, coupled to a client 306, 
which is typically a WEB browser that can have embed- 
ded applications, such as applets, used to generate 
secure http requests (HTTPs). It should be noted 1 that 
in order to assure that no issued credential is stolen or 
otherwise wrongfully used, all connections within the 
enterprise computer system 300 must be substantially 
secure, using, for example, various encryption methods 
well known to those skilled in the art In some imple- 
mentations, a name server 307 is used to identify the 
location (e.g., the address) of the authentication server 
302. 

[0022] The WEB server 304 is also securely cou- 
pled to any number and type of EJB servers 308 - 312. 
ft should be noted that in the described embodiment, 
each of the EJB servers 308 - 31 2 run on top platforms 
I, II, and III, respectively, and therefore are implemented 
as the EJB server 200 shown in Fig. 2. For this example, 
a secure, or protected, external data base 314 that runs 
on top of the platform I is securely connected to the EJB 
server 308. The secure data base 31 4 is typified by data 
bases that contain secure information, related to, for 
example, bank accounts, personal identification, and 
any other type or class of information considered to be 
privileged and therefore protected. In some cases, 
accessing the secure data base 314 requires specific 
privileges not available to all who otherwise have 
access to the data base 314. One such example, is the 
case where the data base 314 Includes, for example, 
payroll information that only specific individuals in an 
organization are granted the privilege to access. In this 
case then, in addition to a general access, a more spe- 
cific privilege is required in order to perform certain 
tasks, such as giving someone a raise. 
[0023] In order for the authentication server 302 to 
provide a credential that affords appropriate access to a 
requesting client (which in this case is the WEB browser 
304), the requesting client must first provide information 
to the authentication server 302 related to, for example, 
specifying which realm to authenticate the client 306 in, 
specifying the authentication method (i.e., BASIC, 
FORW_BASED), and specifying the authentication type 
(i.e., U/P, SSL_CLIENT). 
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[0024] It should be noted that when the authentica- 
tion server 302 has determined which realms (and what 
additional privileges, if any) that requesting client 306 is 
authenticated in, a credential object 316, also referred 
to as a credential, is instantiated. A reference 318 to 5 
that credential is then passed to the client 306 by way of 
the WEB server 304. Since only a reference to the cre- 
dential is passed to the requesting client, any number of 
other clients, such as threads, for example, coupled to 
the authentication server 302 can also reference the w 
same credential. 

[0025] Once the requesting client (i.e., the client 
306) has received the reference to the credential, 
access to any number of secure resources can be 
gained by passing a specific access request along with 75 
the reference to the particular resource to be accessed. 
It should be noted, however, that the credential is only 
valid for those realms for which it was originally been 
authenticated. Therefore, any secure resource located 
in a realm for which authentication has not been granted 20 
will deny the client 306 access until a new credential is 
issued authenticating access to that particular realm, or 
the current credential is updated with the authenticated 
attributes from that realm 

[0026] For example, if a user implementing the cli- 25 
ent 306 desires to access the data base 314 in order to, 
for example, run a payroll program, a secure http 
request (HTTPs) must be generated requesting a cre- 
dential for access to the data base 314. If additional 
privileges beyond mere access are required in order to 30 
complete the transaction, then this fact must be 
included in the information provided by the user. In 
some cases, the authentication server 302 will respond 
back to the WEB server 304 that additional information 
is required, in which case, a question and answer ses- 35 
sion will be initiated until such time as the authentication 
server 302 has determined that it has enough informa- 
tion to either grant or deny a credential to the requesting 
client for the requested realm(s). 

[0027] Once the authentication server has enough <o 
information to process the credential request, it vali- 
dates those realms for which the credential will grant 
access to any client possessing a reference to that cre- 
dential, ft is important to note that since the reference to 
the credential is analogous to a "bearer bond", only 45 
legitimate clients should possess the reference. There- 
fore, using secure lines between the various elements 
of the enterprise computer system 300 is an important 
consideration during design and implementation. The 
authentication server 302 grants or denies a credential so 
based upon the supplied information, and in that case 
when a credential is denied, an error flag is posted to 
the requesting client 306. On the other hand, when the 
authentication server 302 determines that a credential 
should be granted, then a credential object is instanti- 55 
ated and, in one implementation, stored in the authenti- 
cation server 302 and a reference to that credential 
object is passed to the requesting client 306. 



[0028] Once the requesting client 306 has the refer- 
ence to the credential, it forwards a request to access 
the data base 31 4 to the E JB server 308. In one embod- 
iment, the data base access request is accompanied by 
the reference to the credential such that the EJB server 
308 can ascertain that the requesting entity (i.e., the cli- 
ent 306) has the proper authentication to transact busi- 
ness with the data base 314. In some cases, the EJB 
server 308 will be required to access another of the EJB 
servers, such as EJB server 31 0, in order to complete 
the requested transaction. In this case as well, the 
request by the EJB server 308 to the EJB server 310 
also is accompanied by the reference to the credential. 
If the credential is valid for the resources coupled to the 
EJB server 31 0, then access is granted arid the transac- 
tion is completed, other wise access is denied. There- 
fore, it is for at least this reason that when the request is 
made to the authentication server 302 that it requests 
privilege for each realm for which access will be 
required. 

[0029] Rg. 4 is a flowchart detailing a process 400 
for a client for obtaining a credential in order to access 
an object in accordance with an embodiment of the 
invention. It should be noted that the process 400 can 
be sub-divided into two sub-regimes, specifically those 
actions carried out by the requesting client (referred to 
as client side) and those actions carried out by the 
authentication server (referred to as authentication 
server side). In order for a client to conduct a transac- 
tion, it must at some time obtain access to an object or 
some other protected resource. In the described 
embodiment, the client must therefore acquire owner- 
ship of a credential that enables the client, as a creden- 
tial owner, to access particular objects or other 
protected resources in the enterprise computer system. 
In the case where the various resources execute on dif- 
ferent operating platforms, then the requesting client 
must identify these platforms so as to be authenticated 
in order to complete the transaction. 
[0030] The process 400 for obtaining and using a 
credential starts, in one implementation, at 402 by the 
requesting client accessing a name server arranged to 
provide the location, or address, of an authentication 
server. In some embodiments, the name server is not 
required since it only provides the address of the 
authentication server that can be provided by other 
methods well known to those skilled in the art After the 
location of the authentication server is made known to 
the requesting client, the requesting client provides a 
credential request to the authentication server at 404 
passing its address and various data pertinent to the 
authentication. Such pertinent information can include 
the realm(s) for which authentication is necessary to 
complete the anticipated transaction, as well as any 
special privileges required to complete some or all of 
the anticipated transaction. Once the authentication 
server has received the request from the requesting cli- 
ent, the authentication server authenticates the client in 
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the appropriate realm (s) at 406 by instantiating a cre- 
dential object The authentication server then calls a 
translation method on the credential object at 408 and 
returns a reference to the credential object to the 
requesting client at 410. In the described embodiment, 5 
the credential object is stored in the authentication 
server and only a reference to the credential object is 
passed. In this way, multiple threads can access the 
same credential object thereby improving performance 
and efficiency of the enterprise computer system. w 
[0031] Once the requesting client has obtained the 
reference to the credential object, the requesting client 
is capable of providing an object access request in con- 
junction with the reference to the credential object to a 
protected resource at 412. is 
[0032] Fig. 5A is a flowchart detailing the process 
500 for a client requesting a credential form an authen- 
tication server shown in Fig. 4 as operation 404. It 
should be noted that the process 500 is only one possi- 
ble implementation of the operation 404 and as such 20 
should not be construed as limiting the scope or intent 
of the invention. The process 500 begins at 502 when 
the client requests to begin authentication by calling the 
method on the authentication server by passing its own 
address. In response, the requesting client receives an 25 
empty credential at 504 used as a placeholder. Next, at 
506, an authentication request is initiated using authen- 
tication data provided by the requesting client to the 
authentication server. Based upon the authentication 
data, the authentication server initially returns a status 30 
flag at 508. In one state, the status flag indicates a fail 
status meaning that the requesting client has been 
denied authentication based in part on the authentica- 
tion data provided. Such a denial can be based upon 
indicating a realm for which the requesting client is 35 
denied access, or special privileges within an approved 
realm are denied. In any case, the failure flag is 
returned to the requesting client at 51 0. 
[0033] In the case where the status flag is a pass 
flag, then the authentication server passes a reference 40 
to a credential to the requesting client at 41 0. In some 
cases, however, additional information is required of the 
requesting client and in those cases a continue flag is 
returned such that either the client requests more infor- 
mation or provides additional information at 512, after 45 
which control is passed back to 506. 
[0034] In the case where a continue flag is 
returned, Fig. 5B is a transaction diagram detailing the 
request/response between the requesting client and the 
authentication server in accordance with an embodt- so 
ment of the invention. It should be noted that in the case 
of a conditional status flag being returned, there can be 
any number of Interim information exchanges until such 
time as the authentication server is satisfied it has 
enough information to either grant or deny a credential, ss 
[0035] Turning now to Fig. 6 which is a flowchart 
detailing a process 600 for an authentication server 
authenticating a client in appropriate realms shown in 



Fig. 4 as operation 406. It should be noted that the proc- 
ess 600 is only one possible implementation of the 
operation 406 and as such should not be construed as 
limiting the scope or intent of the invention. The process 
600 begins at 602 by the authentication server gather- 
ing authentication data from the requesting client as 
shown for example in Fig. 5B. A determination is made 
at 604 whether or not additional data is required and 
when additional data is not required then the authenti- 
cation server authenticates the requesting client at 606, 
otherwise, more data is gathered by the authentication 
server. If the authentication was deemed to be a suc- 
cess at 608, then control is passed to operation 408 of 
Fig. 4 where the authentication server translates the 
credential. If however, the authentication was deemed 
to be a failure, then a fail flag is returned at 61 0. 
[0036] Fig. 7 is a flowchart detailing a process 700 
for translating the credential by the authentication 
server as shown in Rg. 4 as operation 408. It should be 
noted that the process 700 is only one possible imple- 
mentation of the operation 408 and as such should not 
be construed as limiting the scope or intent of the inven- 
tion. The process 700 starts at 702 by the authentica- 
tion server determining if additional privileges have 
been either requested, or are deemed to be appropri- 
ate. If additional privileges are appropriate, then those 
additional privileges are granted by the authentication 
server to the requesting client at 704. If however, no 
additional privileges arc required, then the credential is, 
in one embodiment, digitally signed in order to prevent 
unauthorized use of the credential at 706 The credential 
is then validated at 708 by, for example, setting an expi- 
ration period after which the credential is subject to 
being destroyed or otherwise being garbage collected. 
At 710, a reference to the validated credential is then 
returned to the requesting client at 41 0. 
[0037] Fig. 8 is a flowchart detailing a process 800 
for accessing an object or other protected resource as 
shown in Rg. 4 as operation 412. It should be noted that 
the process 800 is only one possible implementation of 
the operation 412 and as such should not be construed 
as limiting the scope or intent of the invention, The proc- 
ess 800 begins at 802 by the requesting client initiating 
a protected resource access request. After the pro- 
tected resource receives the resource access request 
at 804, the authentication server validates and verifies 
the associated credential that was presented to the pro- 
tected resource along with the access request at 806. If 
the validation and verification are deemed have been 
unsuccessful at 808 then access is denied at 810, oth- 
erwise, then a determination is made at 812 whether or 
not the credential has the appropriate privileges 
granted. If the appropriate privileges are not granted, 
the access is denied at 810, otherwise the requesting 
client is granted access to the protected resource at 
814. 

[0038] Rg. 9 illustrates a computer system 900 that 
can be employed to implement the present invention. 
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The computer system 900 or, more specifically; CPUs 
902, may be arranged to support a virtual machine, as 
will be appreciated by those skilled in the art. As is well 
known in the art, ROM acts to transfer data and instruc- 
tions uni-directionally to the CPUs 902, while RAM is s 
used typically to transfer data and instructions in a bi- 
directional manner. CPUs 902 may generally include 
any number of processors. Both primary storage 
devices 904, 906 may include any suitable computer- 
readable media. A secondary storage medium 908, w 
which is typically a mass memory device, is also cou- 
pled bi-directionally to CPUs 902 and provides addi- 
tional data storage capacity. The mass memory device 
908 is a computer-readable medium that may be used 
to store programs including computer code, data, and 75 
the like. Typically, mass memory device 908 is a storage 
medium such as a hard disk or a tape which generally 
slower than primary storage devices 904, 906. Mass 
memory storage device 908 may take the form of a 
magnetic or paper tape reader or some other well- 20 
known device It will be appreciated that the information 
retained within the mass memory device 908, may, in 
appropriate cases, be incorporated in standard fashion 
as part of RAM 906 as virtual memory. A specific pri- 
mary storage device 904 such as a CD-ROM may also 25 
pass data uni-directionally to the CPUs 902. 
[0039] CPUs 902 are also coupled to one or more 
input/output devices 910 that may include, but are not 
limited to, devices such as video monitors, track balls, 
mice, keyboards, microphones, touch-sensitive dis- 30 
plays, transducer card readers, magnetic or paper tape 
readers, tablets, styluses, voice or handwriting recog- 
nizers, or other well-known input devices such as, of 
course, other computers. Finally, CPUs 902 optionally 
may be coupled to a computer or telecommunications as 
network, e.g., an Internet network, or an intranet net- 
work, using a network connection as shown generally at 
91 2. With such a network connection, it is contemplated 
that the CPUs 902 might receive information from the 
network, or might output information to the network in 40 
the course of performing the above-described method 
steps. Such information, which is often represented as a 
sequence of instructions to be executed using CPUs 
902, may be received from and outputted to the net- 
work, for example, in the form of a computer data signal 45 
embodied in a carrier wave. The above-described 
devices and materials will be familiar to those of skill in 
the computer hardware and software arts. 
[0040] Although only a few embodiments of the 
present invention have been described, it should be so 
understood that the present invention may be embodied 
in many other specific forms without departing from the 
spirit or the scope of the present invention. 
[0041] Although the methods of providing cross 
platform security protocols in accordance with the ss 
present invention arc particularly suitable for implemen- 
tation with respect to a Java™ based environment, the 
methods may generally be applied in any suitable 



object-based environment. In particular, the methods 
are suitable for use in platform-independent object- 
based environments. It should be appreciated that the 
methods may also be implemented in some distributed 
object-oriented systems. 

[0042] While the present invention has been 
described as being used with a computer system that 
has an associated web browser, it should be appreci- 
ated that the present invention may generally be imple- 
mented on any suitable object-oriented computer 
system. Therefore, the present examples are to be con- 
sidered as illustrative and not restrictive, and the inven- 
tion is not to be limited to the details given herein, but 
may be modified within the scope of the appended 
claims along with their full scope of equivalents. 

Claims 

1. In a distributed object computing system, an 
authentication server arranged to provide a creden- 
tial that grants a credential owner permission to 
access a protected resource identified in authenti- 
cation data included in an associated credential 
request provided by a requesting client, comprising: 

a credential request verifier arranged to deter- 
mine if additional authentication data is 
required by the authentication server in order to 
grant the credential to the requesting client; 
a realm authenticator coupled to the credential 
request verifier arranged to authenticate the 
requesting client in a requested realm when it 
is determined that the requesting client is 
allowed to access the requested realm; 
a credential translator coupled to the realm 
authenticator arranged to grant a requested 
privilege in the authenticated realm to the 
requesting client when it is determined that the 
requesting client is allowed the requested priv- 
ilege in the authenticated realm; and 
a credential generator coupled to the credential 
translator arranged to provide the credential to 
the requesting client 

2. An authentication server as recited in claim 1, 
wherein when the credential request verifier deter- 
mines that additional authentication data is 
required, then the credential request verifier initi- 
ates a session between the requesting client and 
the credential request verifier arranged to provide 
the additional authentication data. 

3. An authentication server as recited in claim 2, 
wherein when it is determined that the requesting 
client is not allowed access to the requested realm, 
then a first type fail flag is posted to the requesting 
client 
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4. An authentication server as recited in claim 3, 
wherein when it is determined that the requesting 
client is not allowed the requested privilege in the 
authenticated realm, then a second type fail flag is 
posted to the requesting client 5 

5. An authentication server as recited in claim 4, 
wherein the credential generator instantiates a cre- 
dential object that resides in the authentication 
server. w 

6. An authentication server as recited in claim 5, 
wherein the credential generator returns a remote 
reference to the credential object to the requesting 
client which is then used to access the protected is 
resource such that the requesting client is the cre- 
dential owner. 

7. A authentication server as recited in claim 6, 
wherein the credential server is securely coupled to 20 
the requesting client. 

8. A authentication server as recited in claim 7, 
wherein the credential server and the requesting 
client are each securely coupled to the protected 25 
resource by way of an Enterprise Java Bean (EJB) 
server, wherein the authentication server, the 
requesting client, and the EJB server together form 

an EJB enterprise computer system. 

30 

9. An authentication server as recited in claim 8, 
wherein when the requesting client requires access 
to the protected resource, the requesting client 
presents a protected access request in addition to 
the reference to the credential to the EJB server. 35 

10. An authentication server as recited in claim 9, 
wherein the EJB server responds to the presenting 
of the reference to the credential by requesting the 
authentication server validate the presented ere- 40 
dential, wherein when the credential is validated, 

the EJB server grants the requesting client access 
to the protected resource, otherwise, the requesting 
client is denied access to the protected resource. 

45 

11. An authentication server as recited in claim 10, 
wherein the requesting client is a web browser. 



pled to the requesting client and a server coupled to 
the protected resource, comprising: 

providing a credential request to the authenti- 
cation server by the requesting client, wherein 
the credential request includes authentication 
data indicative of the protected resource; 
authenticating the requesting client to access 
the protected resource by the authentication 
server base upon the authentication data; 
authenticating the requesting client to exercise 
a privilege associated with the protected 
resource, wherein the privilege is in addition to 
the granted access; 

providing the requesting client with a reference 
to the credential; 

presenting the reference to the credential along 
with a protected resource access request to the 
server; 

validating the credential by the authentication 
server when presented by the server; and 
granting the requesting client access to the 
protected resource by the EJB server when the 
credential is validated. 

1 4. A method as recited in claim 1 3, wherein the server 
is an Enterprise Java Bean (EJB) server. 

15. A method as recited in claim 13, where in the pro- 
tected resource is a data base. 

16. A method as recited in claim 15, wherein the 
requesting client is a web browser. 

17. A method as recited in claim 16, wherein when the 
authentication server denies the credential request 
of the requesting web browser, then the authentica- 
tion server responds by posting a first type fail flag. 

18. A method as recited in claim 16, wherein when the 
authentication server denies the requesting web 
browser the requested privilege, the authentication 
server posts a second type fail flag, whereas the 
authentication server provides the requesting client 
with the credential to access the protected resource 
without the privilege. 



12. An authentication server as recited in claim 1, 
wherein the authentication server has an address so 
location provided by a naming service. 

13. A method of accessing a protected resource in a 
mufti-platform enterprise computer system having 

an authentication server arranged to authenticate a ss 
credential used by a requesting client as a creden- 
tial owner to access the protected resource, 
wherein the authentication server is securely cou- 
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